In order to facilitate communication between communication devices over a network, each network device is typically assigned a unique numeric network address. A user associated with one of the network devices then need only provide the network transport layer with the numeric network address of the intended target to communication with the target. Although this system functions satisfactorily in small network where users only communicate with a small number of network communication devices, the system cannot be readily transported to large networks since it would require each network user to remember a large number of unique numeric network addresses. For this reason, the domain name system (DNS) was proposed by Mockapetris in 1987 (RFC 1034 and RFC 1035, Network Working Group; presently available at “http://www.ietf.org”) as a mechanism for facilitating communication between communication devices over the Internet.
The DNS facilitates Internet communication by associating domain names with the numeric (IP, “Internet Protocol”) network addresses. The DNS basically consists of resource records, domain name servers, and resolvers. Each resource records includes information concerning each network node, including the IP address of the network node, and the domain names associated with the IP address. Together, the resource records provide the Internet with a tree-structured domain name space. Domain name servers are Internet servers which retain information concerning the domain name space. In particular, each domain name server has a file (“zone file”) which retains resource records associated with its own subset of the domain name space. These records are referred to as “authoritative” records. Also, through queries from resolvers, domain name servers also temporarily cache copies of resource records acquired from other domain servers in order to improve the performance of the retrieval process when non-local data is requested by a resolver. Resolvers are local programs which extract information from domain name servers in response to client requests.
Typically, the domain name associated with a network device at particular IP address has a top level label field, and one or more lower level label fields. The label fields comprising a domain name are separated from one another through a delimiter (“.”), and are each positioned in the domain name according to their respective relative levels in the domain name hierarchy. To access a particular network device (including transmitting an e-mail message to a recipient having an e-mail account subsisting at a remote network device) a user provides a resolver, through an Internet browser, with the domain name associated with the target network device. The resolver queries a root DNS server with the top level label identified in the domain name to obtain the IP address of the DNS server which has the zone file associated with the top level domain. The resolver then accesses the identified DNS server using the obtained IP address, and with the label occupying the next highest position in the domain name hierarchy (the label immediately to the left of the top level label in the domain name) obtains the IP address of the DNS server which has the zone file associated with the queried label. The process continues until each label in the domain name has been resolved, at which point the last queried DNS server provides the resolver with the IP address of the network device having the specified domain name. Although the DNS has been implemented successfully worldwide, it suffers from at least three main deficiencies.
First, the domain names implemented by the DNS must follow the rules for ARPANET host names. Consequently, each label must begin and end with a “letter” or one of the numbers 0 to 9, and contain only “letters”, the numbers 0 to 9 or a hyphen in between. Further, each “letter” can only be one of ‘A’ to ‘Z’ and ‘a’ to ‘z’. As a result, the number of domain names available is severely limited. Second, the DNS system is case insensitive, so that two domain names which have identical spellings but whose component letters do not correspond in terms of their respective cases, will resolve to the same network address. As will be apparent, this requirement further limits the number of domain names which can be used. Third, since the resource records for each sub-domain are stored in zone files, the number of domains names and the speed of the resolving process is limited by the hardware restrictions of the domain name servers.
Although e-mail systems existed long before the DNS was established, the problems inherent with existing e-mail systems closely parallel those of the DNS. In particular, most e-mail system only accept, for inclusion as part of an e-mail account name, the hyphen, the numbers 0 to 9 and the letters ‘A’ to ‘Z’ and ‘a’ to ‘z’, thereby limiting the number of account names available. Again, most e-mail systems are also case insensitive, further limiting the number of account names available.
Attempts have been made to resolve some of the deficiencies of the existing network address naming systems. For instance, RealNames (www.realnames.com) and iDNS (ww.idns.org) have proposed modifications to the existing domain name system which attempt to expand upon the number of domain names available. Both systems would allow users to enter a domain name into the URL field of their browser, without the name following the rules for ARPANET host names. For instance, subscribers could enter into their Internet browser a domain name which includes symbols, and/or letters from non-English language character sets. The domain name would be transmitted to a proprietary RealNames or iDNS server which would then translate the domain name into an ARPANET-compliant domain name for resolution by the existing DNS. As will be apparent, these solutions could cause a computation bottleneck since each domain name would have to be translated first by their proprietary servers prior to resolution by a domain name server. Further, these solutions would not be suitable for e-mail addresses since the portion of the e-mail address identifying the originator and recipient of the e-mail message would still need to be translated by the recipient's e-mail POP3 server.
Microsoft Corporation has proposed a solution (http://search.ietf.orf/internet-drafts/draft-skwan-utf8-dns-0.2.txt) which would increase the size of the character set available for domain names. According to the proposal, DNS packets would be migrated from the existing ASCII format to the UTF-8 format. However, this latter solution would require that all Internet browsers be updated before domain names employing UTF-8 characters were used since UTF-8 characters are encoded using a double-byte structure. Consequently, a domain name server, implemented using BIND for example, would incorrectly interpret a UTF-8 character received from a conventional browser as two characters instead of one, resulting in an incorrect resolution of the domain name.
Therefore, there remains a need for a network address naming system which expands upon the number of domain names available, without creating computational bottlenecks and without requiring significant changes to existing browser software. Further, there remains a need for a network address naming system which expands the size of the character set available for the account name component of e-mail addresses.